超大规模云反向迁移——克服6个常见挑战

云遣返。反向云迁移。去云化（我们可能同意这个不应该流行）。

所有这些都表明，越来越多的企业正在摆脱超大规模云计算的束缚，因为它们希望重新获得对长期高昂成本和基础设施锁定的控制。

无论您离开的原因是什么，将基础设施（无论是整体还是部分）从云迁移到不同的生态系统的想法都是令人望而生畏的。但这不应该让您望而却步。一个聪明、深思熟虑的云退出策略考虑到云遣返的常见挑战，将使流程更加精简。

但这些常见的挑战是什么？你又该如何缓解这些挑战呢？

挑战 1：采取分阶段的方法

我们与之合作进行反向云迁移的许多客户只想拿起他们的基础设施并迁移它。但正如我们的游戏客户之一、来自Gameye的 Andrew Walker所描述的那样，基础设施迁移“有点像试图更换行驶中的车辆的轮子”。一次性拆下所有轮子将不可避免地导致灾难。这就是为什么一个好的云退出策略不会一次性完成的原因。事实上，我们有一些客户花了长达 18 个月的时间才完全从云中迁移出来。

当然，有些情况下这是不可能的。例如，如果你是一家匆忙建立基础设施的初创公司，无法轻松地将其与超大规模环境分离。你需要先花时间在云端重新架构，以便分离，然后可能需要一次性提升和转移基础设施，然后才能进入下一个增长阶段。

对于大多数可以采用分阶段方法的公司来说，花时间真正了解您的基础设施直至细节至关重要：

• 它是如何设计的？
• 集成了哪些产品？
• 您正在使用什么服务器？
• 您的每月账单包含哪些内容？
• 哪些系统耦合如此紧密以致于无法位于不同的数据中心？

只有完成这项工作后，您才应该开始考虑替代环境。因为没有这些知识，您就无法真正弄清楚新环境需要什么样子，以及迁移到新平台需要做什么。

但一般来说，为了在反向云迁移过程中尽可能减少影响，请确定基础设施的哪一部分可能对日常运营影响最小，并首先迁移该部分。完成后，从过程中吸取教训 - 看看哪些有效，哪些无效 - 然后进入迁移的下一阶段。

在一篇详细介绍其云退出策略的博客中，SaaS 提供商 Prerender 概述了分阶段迁移的成功——“我们通过仔细规划迁移的每个阶段、在扩展之前测试每个实施阶段以及在出现任何问题时轻松纠正任何错误来避免危险。这样，我们可以节省服务器费用，同时将任何潜在风险降至最低。”

挑战 2：引入新技术

超大规模云提供商因其将公司基础设施锁定在其平台上的能力而臭名昭著。这意味着他们让你很难在其他地方复制完全相同的环境 - 您可能需要聘请或外包专家来帮助你寻找或创建替代解决方案。

例如：

• 您正在使用 AWS 可扩展数据库产品，该产品会自动为您选择最佳实例类型。如果其他环境中没有此产品，您将需要手动选择正确的实例类型，但您可能不具备这样做的知识或经验。
• 同样，一些超大规模云产品的设计使得您无法获得替代解决方案的类似报价。例如，如果您曾经通过超大规模云提供商购买过平台即服务产品，您就会知道设置和计费模型有多么复杂，以解释每种产品的复杂性。以至于有些人通过帮助公司在超大规模云中建立环境并解读每月账单来获得职业（和大量金钱）。如果您发现自己在超大规模环境中使用此类产品，我建议您聘请或与知道如何将超大规模云中的某种产品转换为不同技术的人合作。

这里最大的收获是要准备好探索新的设置方法甚至新技术。您可能无法在新环境中使用与超大规模相同的数据库或应用程序。例如当 Remoby 从 AWS 迁移到我们的裸机环境时。

“总体而言，迁移过程对我们来说非常顺利。我们面临的唯一挑战是，在 AWS 中，我们使用名为 Amazon EKS 的 k8s 即服务，并简单地向其中添加了必要的节点，然后为我们的服务配置了 Helm 图表。这与 servers.com 管理的 K8s 服务不太一样，有一段时间我们准备放弃迁移的想法。幸运的是，我们设法与 servers.com 团队合作，想出了一个解决方案，让我们能够快速而愉快地取得进展，” Remoby 首席技术官 Sergey Chernukhin 说。

Gameye 的 Andrew 也曾帮助游戏公司进行反向云迁移，他指出，有时“需要更改 UI，因为匹配器在另一个环境中的工作方式与在超大规模设置中不太一样”。了解此类差异很重要，因为在这种情况下，如果游戏公司已经推出其游戏，游戏体验可能会发生变化。

因此，在迁移后要做好对应用程序进行一些调整的准备。令人惊讶的是，即使在型号略有不同的同一供应商硬件之间移动工作负载也会导致应用程序的行为有所不同。

挑战 3：合理规模

这与上面引入新技术的挑战密切相关。所谓合适规模，是指当您离开超大规模环境时，您会转移到适合您需求的服务器。这听起来可能很明显，但您很可能会在超大规模云中过度配置或配置不足您的生态系统。

如上所述，关键是要查看并充分了解与超大规模环境相关的统计数据，以便在迁移时可以选择反映您实际需要的服务器。

如果您选择与托管合作伙伴合作构建新环境，规划过程应包括与该合作伙伴进行深入的概念验证。这将使您有机会测试不同的机器设置，以确保您拥有最适合自己的机器设置。

挑战 4：迁移数据

这也许是迁移难题中最难的部分。迁移数据可能需要几天甚至几周才能完成，具体取决于您的数据集有多大。对于一些公司来说，这段时间可能不是问题。或者您甚至可能没有任何数据需要迁移，例如一些基于会话且不保留每个会话数据的游戏服务器。对于大多数其他全天候运行并使用数据库存储实时数据的企业来说，时间更为重要。

将数据迁移出超大规模环境主要有两种方式。具体选择哪种方式取决于数据集的类型和大小。

选项 1：物理备份

这涉及超大规模云提供商将您的数据上传到磁盘，然后他们会将这些数据传递给您，以便您将其插入到新环境中。使用这种方法时，重要的是要记住，上传到磁盘的数据是某个时间点的数据。假设数据在星期五上传到磁盘，但直到星期一才添加到新环境中，那么您就丢失了两到三天的数据。

也就是说，如果您要传输 TB 级甚至 PB 级的数据，它有时可能比虚拟传输数据更快。

选项 2：虚拟备份

顾名思义，这种方法涉及通过互联网传输数据。如果数据集很大，通过互联网传输数据可能比物理传输花费更长的时间。即使数据集较小，需要六个小时才能传输，您仍然有六个小时的更改在迁移过程中没有被捕获。然后，您需要继续传输数据以覆盖所有差异，直到您将其缩小到与客户安排维护窗口以传输剩余数据的地步。

这个维护窗口点很重要。虽然我很想说，你可以在不影响客户的情况下进行迁移，但这不现实。然而，接受这一点意味着你可以为此做好计划，以将影响降到最低。无论你选择哪种数据迁移路径，都至少包括一次计划维护，并提前向客户明确传达。

挑战 5：重复成本

大多数迁移项目都遵循类似的流程。首先，您需要在新环境中启动基础设施，同时保留在超大规模云提供商中设置的主要生产环境。完成后，您需要将服务器上线 - 添加网络、安装操作系统和虚拟机管理程序（如果您在虚拟环境中）、构建应用程序堆栈并配置所有内容。

这意味着，根据您要迁移的生态系统的规模和复杂程度，您需要在一段时间内同时支付两个基础设施环境的费用。这是为了确保生态系统在新环境中正常运行，并让您之前的基础设施的迁移完全完成。

对于交易平台FxGrow来说，“我们花了两周时间才完全迁移到新的托管服务提供商。我们一直在向之前的托管服务提供商和新托管服务提供商付费，直到迁移完成”。他们的迁移时间框架由公司使用的关键应用程序 MetaTrader 5 决定，以确保在迁移期间停机时间尽可能短。

并行迁移是常态，因此，重复成本也是如此。但如果您没有为此做好计划，那么在迁移项目的某个阶段，它当然会成为一项挑战。为了避免这种情况，请在流程开始时就建立重复成本。当您制定迁移计划和预算时，请在预算中列出一个项目，以说明交叉期。

如果您有需要持续正常运行时间的应用程序，请遵循 FxGrow 的示例并与该应用程序的提供商联系，以获取有关迁移时间的建议。

挑战 6：识别与第三方的连接

大多数公司的基础设施生态系统不仅由内部连接支持，还与多个第三方提供商相连。组织规模越大，多年来其发展就越有机，而且您很可能拥有您甚至不知道的第三方连接。

例如，对于大多数广告技术提供商来说，他们的流量来自合作伙伴，因此如果他们更改其 IP 地址，他们必须通知其合作伙伴，并且可能会有一个围绕他们转移到新 IP 的 SLA。

作为迁移规划过程的一部分，对所有第三方连接进行彻底审核并清晰地记录下来。

如果您选择与合作伙伴合作来托管您的新基础设施环境（例如基础设施即服务 (IaaS)提供商），他们将与您一起制定计划，以确保每个第三方连接都成功迁移。

良好的规划需要成为云退出战略的核心

所有这六个挑战都有一个首要主题——规划。

迁移并不是公司经常做的事情。事实上，负责执行迁移的系统管理员可能多年都没有做过迁移了。

这就是为什么成功地将云反向迁移到裸机、本地和主机托管需要您进行规划，然后再次规划，直到您觉得对可能出现的任何问题或突发事件都有应对措施。

无论您选择哪条路线，都要准备好投入研究、时间和金钱来创建一个您确信会为您和您的客户带来最少停机时间的云退出策略。

隧道的尽头是更大的独立性、灵活性以及更为舒适的基础设施账单。